There has been increasing recognition in recent years of the need to design software products and Web pages with consideration for the needs of people with disabilities, to avoid excluding certain groups of individuals from access to information technology and information content. Recent legislation from the US and UK Governments and in other countries has made it mandatory to facilitate access to goods and services for disabled people, and this has emphasized the importance of software vendors and information providers moving towards more accessible software products. Furthermore, with appropriate solutions to accessibility issues, the World Wide Web internet service and information technology in general can provide a very useful service to blind and partially-sighted people which increases their self-reliance and their ability to proactively participate in information exchange.
One of the important ways a software product can be made accessible is for it to work correctly with screen reader programs. These programs read aloud information displayed on the screen, or convert screen information to Braille, so that users who are blind or partially sighted can access the software product. A number of GUI screen reader products are currently available, including Screen Reader/2™ from International Business Machines Corporation, Jaws™ for Windows™ from Henter-Joyce Inc., Winvision™ from Arctic Technologies Inc., and Outspoken™ for Windows from Berkeley Access. Many of these screen readers are able to read icons and other graphical objects. For example, the Outspoken screen reader converts dialog boxes, radio buttons and other graphical controls to audible output, and can be used with many application programs developed for the Windows operating system.
When a software product has dialogs or panels that require the user to enter data or other information, they typically have one or more lines of text describing the data to be entered, using a control known as a ‘static text control’, followed by an entry field where the user types the data (an ‘edit control’). The screen reader software looks for the static text control immediately before the edit control, and reads this aloud to the user as a prompt as to what to enter at that point. The elements of the dialog or panel are typically defined in a file as an ordered list of controls, and the screen reader will usually read aloud the controls in the order in which they appear in this list. For the screen reader to read the dialog or panel in the correct logical order, the controls must be in this list in the correct order. For a typical screen reader to work correctly with prompts for entry fields, it is important that:    1) the prompt for the edit control is implemented using a static text control; and    2) the correct static text control is immediately before the edit control in the dialog or panel definition file.
Previous attempts to enable the operation of a screen reader have relied on providing “accessibility” guidelines for designers of user interfaces—if user interfaces are designed, or redesigned, to conform to the guidelines then the standard screen readers will be able to read and interpret graphic as well as text elements and to present them in the correct sequence.
However, legacy programs written before software vendors focussed on accessibility requirements of disabled people can have many dialog and panel definitions which do not meet these rules, and each definition may have been translated into many languages if the software products are sold in many different countries. Since the dialog or panel will usually appear visually correct whatever the order of the controls in the definition, the precise sequence only becomes significant when considering compatibility with screen reader programs. The legacy programs may also use controls other than static text controls as the prompt field for edit fields, for example a ‘radio button’ control which allows the user to choose only one from a range of choices—in this case an entry field may be used to enter a parameter only if a particular choice is made. A screen reader which is designed to read out the text of a static text control associated with an edit control will not work correctly if the prompt is a radio button control, and it will not read out elements in the correct order if the order of controls within a dialog or panel definition is incorrect.
For programmers to test and make changes to the order of controls or to add controls within all the dialog and panel definitions across multiple language versions of a complex software product to ensure correct operation of screen readers would be a long and error-prone task, and would be likely to result in dialogs and panels that were visually different from those that existing users are familiar with and which are shown in the product documentation.
U.S. Pat. No. 6,144,377 discloses an architecture for enabling an accessibility aid such as a screen reader program to access and manipulate user interface (UI) elements of an application program, including graphical elements such as edit boxes and buttons. According to U.S. Pat. No. 6,144,377, a screen reader is enabled to access the program code and data which implements a UI element, to examine and manipulate various characteristics of the UI element such as its location or text description. However, U.S. Pat. No. 6,144,377 includes no disclosure of the problem of a typical screen reader being unable to read screen information completely or in the correct order if the controls or the order of those controls within a user interface element definition is different from that expected by the screen reader.